@adriaanm Through test failures here I discovered two problems with the LUB approach. The first is the failing test `tests/pos/overloaded.scala'. Here we find:

def combine(f: (Char, Int) => Int): Int = ???
def combine(f: (String, Int) => String): String = ???
val r5 = combine((x: Char, y) => x + y)
val t5: Int = r5
val r6 = combine((x: String, y) => x ++ y.toString)
val t6: String = r6

This used to compile OK, but now gives errors, and scalac produces errors as well:

/Users/odersky/workspace/dotty/tests/pos/overloaded.scala:46: error: type mismatch;
 found   : (Char, Int) => Int
 required: (Any, Int) => ?
  val r5 = combine((x: Char, y) => x + y)
                                ^
/Users/odersky/workspace/dotty/tests/pos/overloaded.scala:48: error: type mismatch;
 found   : (String, Int) => String
 required: (Any, Int) => ?
  val r6 = combine((x: String, y) => x ++ y.toString)
                                  ^

It seems we need a finer resolution which only LUBS those arguments that do not already have a type declared.

The second problem is dotty only, in test file tests/neg/overloaded.scala. Here we have:

def mapX(f: Char => Char): String = ???
def mapX[U](f: U => U): U = ???
mapX(x => x) // error: missing parameter type

We used to get a missing parameter type, but with the LUB change this now compiles into non-sensical code:

Test.mapX[Char^](
  {
    def $anonfun(x: U | Char): U | Char = x
    closure($anonfun)
  }
)

There's an unbound U in the closure. It seems we must get rid of type parameters somehow in the lub. The "same parameter types" approach does not suffer this problem because local type parameters in parameter types would always render them different to other parameter types.

The last commit implements the selective LUB change. But the leaking local parameter problem still persists.

I am going to close this, because the second problem mentioned above looks too messy to solve, given the limited usefulness.

There's an unbound U in the closure. It seems we must get rid of type parameters somehow in the lub. The "same parameter types" approach does not suffer this problem because local type parameters in parameter types would always render them different to other parameter types.

It seems we must get rid of type parameters somehow in the lub.

Yes, we approximate abstract types with (unbounded) wildcards. I'll keep an eye on the dotty approach and the collections rework to make sure we stay compatible.